1. Field of the Invention
The present invention relates to network forwarding devices and, more particularly, to a network forwarding device and method that forward timing packets through the device with a constant delay.
2. Description of the Related Art
The local clocks in network terminal devices, such as sensors, actuators, and computers, can be synchronized to a master clock in a network timeserver in a number of ways. Once synchronized, the local clocks in the terminal devices track the master clock (within a range of accuracy), thereby allowing events to be time stamped with a common frame of reference.
One well-known approach to synchronizing a local clock to a master clock is defined by the Network Time Protocol (NTP), such as NTP version 3, which has been formalized in RFC 1305. To synchronize the local clock of a terminal (network time client) under the NTP protocol, the network time client inserts an originate time stamp into an NTP data packet, and then outputs then NTP data packet to a network timeserver. The originate time stamp indicates when the NTP data packet was output by the network time client to the network timeserver.
The network timeserver receives the NTP data packet, and inserts a receive time stamp into the NTP data packet. The receive time stamp indicates when the NTP data packet was received by the network timeserver from the network time client. After the receive time stamp has been inserted, the network timeserver inserts a transmit time stamp into the NTP data packet, and sends the NTP data packet back to the network time client. The transmit time stamp indicates when the NTP data packet was output from the network timeserver to the network time client. In addition, when the network time client receives the NTP data packet, the network time client inserts a reference time stamp into the NTP data packet that indicates when the NTP data packet was received from the network timeserver.
The offset OFS needed to synchronize the local clock of the network time client to the master clock of the network timeserver is defined by equation EQ. 1 as:OFS=((RCVts−ORGts)+(TRANts−REFts))/2  EQ. 1where RCVts is the receive time stamp, ORGts is the originate time stamp, TRANts is the transmit time stamp, and REFts is the reference time stamp.
FIGS. 1A-1D show timing diagrams that illustrate a prior-art NTP synchronization exchange. As shown in FIG. 1A, a network time client inserts an originate time stamp of time tORG=1000, as measured by the local clock, into an NTP packet, and then outputs the NTP packet to a network timeserver. As shown in FIG. 1B, the network timeserver receives the NTP packet at time tRCV=1051, as measured by the master clock, and then inserts a receive time stamp of t=1051 into the NTP packet.
As shown in FIG. 1C, after an internal delay of four clock cycles, the network timeserver inserts a transmit time stamp of time tTRANS=1055, as measured by the master clock, into the NTP packet, and then outputs the NTP packet to the network time client. As shown in FIG. 1D, the network time client receives the NTP packet at time tREF=1006 as measured by the local clock.
Substituting the example values into equation EQ. 1 provides: OFS=(1006−1055)+(1000−1051)/2=(−49)+(−51)/2=−100/2=−50. An offset OFS of −50 indicates that the local clock trails the master clock by a count of 50. As a result, the network time client adds a count of 50 to the local clock to synchronize the local clock with the master clock.
As further shown in FIGS. 1A-1D, during a subsequent time, the network time client inserts an originate time stamp of time tORG=2000, as measured by the local clock, into an NTP packet, and then outputs the NTP packet to the network timeserver. As shown in FIG. 1B, the network timeserver receives the NTP packet at time tRCV=2001, as measured by the master clock, and then inserts a receive time stamp of tRCV=2001 into the NTP packet.
As shown in FIG. 1C, after an internal delay of four clock cycles, the network timeserver inserts a transmit time stamp of time tTRANS=2005, as measured by the master clock, into the NTP packet, and then outputs the NTP packet to the network time client. As shown in FIG. 1D, the network time client receives the NTP packet at time tREF=2006 as measured by the local clock.
Substituting the example values into equation EQ. 1 provides: OFS=((2006−2005)+(2000−2001))/2=(1+(−1))/2=0/2, which indicates that the local clock and the master clock are synchronized. The process runs continuously in the background to insure that the clocks remain synchronized.
An enhancement to the prior-art NTP synchronization exchange is described in U.S. Patent Application No. 2002 0039370 to Elliot. In Elliot, when an NTP packet is constructed, the originate time stamp inserted into the NTP packet is a predetermined future time. The NTP packet is then placed into an output buffer in the network time client and, when the local clock matches the originate time stamp within the NTP packet, the network time client outputs the NTP packet to the network timeserver at precisely the correct time.
A similar approach is utilized on the return leg. The network timeserver inserts a transmit time stamp into the NTP packet that is a predefined future time. The NTP packet is then placed into an output buffer in the network timeserver and, when the master clock matches the transmit time stamp within the NTP packet, the network timeserver outputs the NTP packet to the network time client at precisely the correct time.
Thus, the network time client in the Elliot patent application outputs the NTP packet with an originate time stamp that precisely matches the actual local time that the packet is output. Similarly, the network timeserver outputs the NTP packet with a transmit time stamp that precisely matches the actual master time that the packet is output. As a result, the enhanced NTP synchronization exchange described by Elliot provides a higher degree of accuracy than does the standard NTP synchronization exchange.
Another common approach to synchronizing a local clock to a master clock is defined by the IEEE 1588 Standard Precision Time Protocol (PTP). The PTP protocol is a two step process, which begins by determining an offset correction. During the first step, the network timeserver outputs a synchronization message and then, after a predetermined time, outputs a follow-up message.
A network time client receives the synchronization message, and adds a client received time stamp to the synchronization message that indicates when the network time client received the synchronization message. The network timeserver, in turn, inserts into the follow-up message a timeserver transmit time stamp that indicates when the network timeserver output the prior synchronization message.
The offset correction OCR can be defined by equation EQ. 2 as:OCR=SRT−MTT−DLY  EQ. 2where SRT is the client received time stamp, MTT is the timeserver transmit time stamp, and DLY is the delay, a value presently unknown and set to zero.
FIGS. 2A-2B show timing diagrams that illustrate the first step of a prior-art PTP synchronization exchange. As shown in FIG. 2A, a network timeserver outputs a PTP synchronization message at time t=1000, as measured by the master clock in the network timeserver. As shown in FIG. 2B, the network time client receives the PTP message at time t=1060, as measured by the local clock, and then adds a receive time stamp of t=1060 to the PTP message.
As further shown in FIG. 2A, after the predetermined time, the network timeserver outputs a PTP follow-up message at time t=1010, which includes as a data field time t=1000, the time that the network timeserver originally sent the synchronization message. As shown in FIG. 2B, the network time client then receives the follow-up message.
Substituting the example values into equation EQ. 2 provides: OCR=1060−1000−DLY=+60. An offset correction OCR of +60 indicates that the local clock leads the master clock by a count of 60 (assuming no delay).
During the second step, which determines the delay, the network time client records the local clock, and outputs a delay request packet to the network timeserver. The network timeserver receives the delay request packet, and records the master clock time that the delay request packet was received. The network timeserver then generates a delay response packet, which includes the master clock time that the delay request packet was received, and outputs the delay response packet back to the network time client.
The delay DLY is defined by equation EQ. 3 as:DLY=((SRT−MTT)+(MRS−STM))/2  EQ. 3where MRS is the timeserver received time stamp and STM is the client transmit time stamp.
FIGS. 3A-3D show timing diagrams that illustrate the second step of a prior-art PTP synchronization exchange. As shown in FIG. 3A, the network time client records a local clock time of t=2000, and outputs a delay request packet to the network timeserver. As shown in FIG. 3B, the network timeserver receives the delay request packet at time t=1960, and records the master clock time that the delay request packet was received.
As shown in FIG. 3C, the network timeserver then generates a delay response packet, which includes the master clock time of t=1960 that the delay request packet was received, and outputs the delay response packet to the network time client at t=1970. As shown in FIG. 3D, the network time client then receives the delay response packet.
Substituting the example values into equation EQ. 3 provides: OCR=1060−1000−((1060−1000)+(1960−2000))/2=60−20/2=+50. A delay DLY of +50 indicates that the local clock trails the master clock by a count of 50. As a result, the network time client adds a count of 50 to the local clock to become synchronized with the master clock.
Regardless of whether the NTP or PTP protocol is utilized, one problem with these protocols is that they do not account for the variable latency (such as queuing delay) that is present in conventional network forwarding devices, such as repeaters, hubs, switches, routers, multiplexers, and concentrators.
In other words, these network forwarding devices can have a delay of X in the upstream direction, and a delay of Y in the downstream direction. Both the NTP and PTP protocols, however, assume that the delay in the upstream and downstream directions is the same. Clock accuracy degrades significantly when this assumption no longer holds true, such as when a NTP data packet or a PTP message must pass through a conventional forwarding device.
One PTP approach to remove the variable delay introduced by conventional network forwarding devices is to instead use network forwarding devices that support IEEE 1588 time synchronization on the network paths that lie between the network time clients and the master clock source. This approach, known as boundary clocks, requires that each forwarding device support full master, full slave, and the best master algorithm.
Another approach utilized with both the PTP and NTP protocols is the use of transparent switches. In a PTP context, a transparent switch is a network forwarding device that time stamps both the receipt of a synchronization message by the forwarding device, and the transmission of the synchronization message by the forwarding device.
The network forwarding device then identifies the subsequent follow-up message that corresponds with the synchronization message, and inserts the receipt and transmission time stamps generated by the forwarding device into the follow-up message. To determine the delay through the network forwarding device from the network timeserver to the network time client, the network time client utilizes the difference between the transmission and receipt time stamps.
On the other hand, to determine the delay through the network forwarding device from the network time client to the network timeserver, the network forwarding device time stamps both the receipt of a delay request packet by the forwarding device, and the transmission of the delay request packet by the forwarding device.
The network forwarding device then identifies the subsequent delay response packet that corresponds with the delay request packet, and inserts the receipt and transmission time stamps generated by the forwarding device into the delay response packet. The network time client then utilizes the difference between the transmission and receipt time stamps within the delay response packet to determine the delay through the forwarding device from the network time client to the network timeserver.
In an NTP context, a transparent switch is a network forwarding device that time stamps both the receipt of an NTP data packet by the forwarding device from a network time client, and the transmission of the NTP data packet by the forwarding device to a network timeserver in the same manner that a delay request packet is time stamped. The network forwarding device also requires a means for determining the delay through the forwarding device from the network timeserver to the network time client.
The network forwarding device then identifies the NTP data packet on its way back from the network timeserver to the network time client (such as by the originate time stamp). Following this, the network forwarding device modifies the receive time stamp in the NTP data packet to account for the delay through the forwarding device from the network time client to the network timeserver based on the transmission and receipt time stamps. In addition, the network forwarding device also modifies the transmit time stamp based on the means used for determining the delay through the forwarding device from the network timeserver to the network time client.
Although these concepts provide methods of addressing the variable latency of standard network forwarding devices, there remains a need for a simple approach to removing this variability.